Date: Mon,  6 Dec 93 04:30:27 PST
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #137
To: Ham-Digital


Ham-Digital Digest          Mon,  6 Dec 93       Volume 93 : Issue  137

Today's Topics:
                        HAM-server index file
             KPC-3: Remote Station Gets 'Busy' Replies??
                      MICOR on 9.6kbaud packet?
                       PK-88 vs KPC-3 vs DPK-2
                 Recent APRS posts from the .ampr net
                         TEKK Radios (3 msgs)
                             unsubscribe
      Who should use gateways for what (was Re: wb7tpy gateway)

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 5 Dec 93 01:35:57 GMT
From: ogicse!cs.uoregon.edu!sgiblab!pacbell.com!amdahl!grafex!ka6etb@network.ucsd.edu
Subject: HAM-server index file
To: ham-digital@ucsd.edu

In <9312022028591.gilbaronw0mn.DLITE@delphi.com> gilbaronw0mn@delphi.com (Gilbert Baron) writes:
>>>Phooey on you Gil! I for one am glad to see the list of files. This  
>>>ham-server is a gold mine of info - I've gotten so many goodies off

>That is what the index is for. Go and read the index yourself and then get
>what you need. Don't subject the rest of the network to this. It is not
>needed and waste time and space and LOTS of money.

Probably no more costly than the AMSAT or KEPLER info published on a much
more regular basis.

Boy, are you gonna be peeved when I get HAM-server set up for PBBS.

73 de KA6ETB

------------------------------

Date: Fri, 03 Dec 93 12:26:43 EST
From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!news.yale.edu!YaleVM.YCC.Yale.Edu!MIKEN@network.ucsd.edu
Subject: KPC-3: Remote Station Gets 'Busy' Replies??
To: ham-digital@ucsd.edu

 
What software are you using with the TNC?
Miken@yalevm.cis.yale.edu
N1JJX@N1JJX.AMPR.ORG
In article <97124@cup.portal.com>
 
 
AllanWS@cup.portal.com (Allan BA Schlaugat) writes:
 
>This problem is making me lose more hair than I have on my head!
>
>I have a KPC-3 TNC which I use to connect to the local PacketCluster.
>The cluster sysop set up a script where if the path between the cluster
>and my location drops and I retry out, the cluster will attempt to reconnect
>to my TNC. This is how I discovered the 'problem'...
>With the computer off (a 386 clone), leaving the TNC/radio on, a station
>cannot connect to my TNC. They receive a ***busy on their end and I get
>a *** connect request! Note that the remote station is not trying to
>access the KA-Node or the mailbox; he is just trying to connect to my
>normal user ID. When I turn the computer on and boot up my packet software,
>I get a buffer full of *** connect requests as well as other channel
>traffic. Stations can now connect to me. It seems that I must keep the
>computer on with terminal software loaded up but this does not seem right.
>I have been involved with packet for 3 years and have used the MFJ-1278
>with no problems. In fact, I cannot reproduce this problem with the
>MFJ. Some locals suggested CTS/RTS hardware flow control might
>be at fault here. I have my USERS set at 10 /MAXUSERS at 10 btw.
>Is there anything I am overlooking here? The KPC-3 is 3 weeks old
>and I never got this thing to work like the MFJ (KPC firmware is
>5.1). Any clues??
>
>Thanks
>
>Al Schlaugat  / allanws@cup.portal.com  \ Amateur Radio: N9ISN

------------------------------

Date: 6 Dec 1993 02:52:08 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
Subject: MICOR on 9.6kbaud packet?
To: ham-digital@ucsd.edu

UHF MICORs work fine at 9600 bps.  Just shove the transmitted data stream
into the modulator, which direct-FMs the offset oscillator.  Pick the
received data off pin 6 of the demodulator chip.  As with most
commercial radios, the IFs are just a tiny bit too narrow for 9600,
but will work well if the signals are at least a few microvolts.

A word of caution: UHF mobile Micor output transistors are no longer available.
These are highly-inefficient early RF devices, and tend to be somewhat
fragile in repeater service.  Pick up a few extra radios for spare parts.

Also, they're real power wasters.  Be sure to have a fan on the heatsink
if you're going to be using it in repeater or BBS service.
 - Brian

------------------------------

Date: Thu, 02 Dec 93 18:43:01 MST
From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!asuvax!ennews!stat!aznet!dan@network.ucsd.edu
Subject: PK-88 vs KPC-3 vs DPK-2
To: ham-digital@ucsd.edu

rdewan@casbah.acns.nwu.edu (Rajiv Dewan) writes:

> On a comparison of Pk88, DPK-2 and KPC-3, Bob Nielsen <w6swe@w6swe.tapr.ORG> 
> wrote:
> > 
> >All three of them run KISS.  The DPK-2 is the only one which has 
> >firmware which is completely compatible with TAPR firmware.  Any 
> >of these can be upgraded to 'open squelch' operation using a 
> >$15.00 kit from TAPR.  The PK-88 and DPK-2 both can be adapted to 
> >use external modems, but the KPC-3 cannot. 
> >...
> 
> The KPC-3 comes ready to run "open squelch" right out of the box.  All
> it needs are two commands:
> 
>     interface terminal
>     cd software

THE ONLY PROBLEM IS THAT IT IS SOFTWARE OPEN SQUELCH AND FALSES A GREAT DEAL!

> 
> Rajiv
> aa9ch
> r-dewan@nwu.edu

Dan


----------------------
  dan@aznet.stat.com
  Daniel J. Meredith
  Fax - (602) 956-2566
Voice - (602) 809-0555

------------------------------

Date: Sun, 5 Dec 1993 18:33:15 GMT
From: csus.edu!netcom.com!rander@decwrl.dec.com
Subject: Recent APRS posts from the .ampr net
To: ham-digital@ucsd.edu

This post is a relay of some recent traffic on the packet network
about the APRS. For those who aren't familiar, APRS is the
"Automatic Packet Reporting System" by WB4APR that allows position
data from a GPS or LORAN receiver to automatically be sent out by
a TNC and then displayed on a map display be other stations running 
APRS.

--------------------included messages follow--------------------------

Date: 04 Dec 93 15:26
Message-ID: <28974@KA6EYH>
From: W7KKE@KA6EYH
To: APRS@ALLCAN
Subject: New/Modified APRS maps
Path: KI6EH!N6IYA!N6QMY!WA8DRZ!WD6CMU!KA6EYH!KA6EYH

From: W7KKE@KA6EYH.#NOCAL.CA.USA.NA
To  : APRS@ALLCAN


I have uploaded some new and updated APRS maps to the KA6EYH LLBBS. This
BBS can be reached at 415-359-6985. Login with your callsign and use the
password "COAST".

The maps are in the APRS directory. This BBS uses standard packet BBS
commands, plus semi-DOS commands. It supports Xmodem and Ymodem in the 
land-line mode.

To download a file using Xmodem use the following commands after log-in:

D              - Sets you in FBBDOS mode
cd APRS        - Changes current directory to APRS
dir            - Lists contents of the directory
XGET filename  - Sets up file transfer via Xmodem.

After you are finished transfering files,

Exit           - Returns to packet BBS mode

The new/updated maps in the APRS directory are:
   
    CALIF.MAP    - Filled the map shell WB4APR sends with his distribution disk
                   with more northern & central California roads.
    
    CAOBISBO.MAP  - Covers south central coast between CA-LA.MAP and
                    CAGILROY.MAP

    CA_DALY.MAP   - Covers Daly City, San Bruno, Colma, and      
                    Burlingame, and South San Francisco.
                    (Includes corrections from WB6LPG's GPS trips)

    CAFSTRCTY.MAP  - Covers Foster City and Redwood Shores area.  
                    This is expanded from the map on the WB4APRS 
                    distribution disk in that it includes Redwood 
                    Shores.
                    (Includes corrections from WB6LPG's GPS trips)

    CA_MATEO.MAP  - Covers San Mateo, part of Burlingame, San    
                    Carlos, Belmont, and a bit of Redwood City.
                    (Includes corrections from WB6LPG's GPS trips)

    HALFMOON.MAP - Covers from Halfmoon Bay airport south to Pigeon Pt. and
                   east to Skyline Blvd.
                   (Includes partial corrections from WB6LPG's GPS trips)
73, Ken W7KKE @ KA6EYH.#NOCAL.CA.USA




Date: 04 Dec 93 17:43
Message-ID: <28010@WB3V>
From: WB4APR@WB3V
To: APRS@ALLUS
Subject: APRS Football Tracking Success!
Path: KI6EH!N6IYA!WD6CMU!KA6EYH!KA6EYH!WX3K!KI7AE!KQ4OK ...

This year we had three packet/GPS trackers attached to the chase vehicles for
the Army/Navy game footbal run from Annapolis MD to the Meadowlands outside
of NY City on 3 Dec.  We were able to track the 1 watt 2m devices over the
full 250 miles!  Volunteer packet stations all along the route left their
TNC's on so that we could use them as digipeaters, and W2HOB put up a
temporary digi in southern NJ at 600 feet!  Using only three hops, the once
every 2 minute position reports made it all along the route ust fine!

Lessons learned:  ALthough the position reports were very reliable, APRS
messages to the mobiles often took 10's of minutes to be ACKed (if at all)
towards the end of the route.  This is the same reason that DIGI's are poor
performers in normal packet.  Ii is simple.  If there is a 20% chance that a
packet gets through the 3 digipeater path, then there is only a 4% chance that
the ACK will get back to the sender!  This is one of the main reasons that
APRS avoids CONNECTED packet and ACKS.  (I am working on an improved message
send capability for APRS that tries to mimimize the need for ACKS)

Direction finding:  With all the vehicles 100 miles out of Annapolis, a stuck
transmitter in Baltimore jammed the frequency for 2 hours solid.  Fortunately
position reports were still being digipeated forward through the network into
NJ, and N2CZF was digipeating them out onto the 40m HF APRS net, so that we
still got the reports!  All activity in Annapolis turned toward DFing.  In
minutes we had crossed bearing lines, but as more and more non APRS stations
got involved the bearings deteriated!  Later we found out that some reports
were given by apartment dwellers moving around in their apartments with HT's
and telling us which corner of their rooms gave the strongest signal! 
Although APRS plotted all these lines well, there was no real convergence. 
But since there was only one other APRS station on the map anywhere within 10
miles of the mess of lines, he was not home!  When he finally was reached
several hours later, long after the signal had disappeared, he could find no
evidence that it was his transmitter.  Anyway, as soon as the signal quit, the
position reports came rolling in and all was well!

OTHERS:  In addition to the GPS equipped chase vehicles, we also saw two other
APRS GPS vehicles join the fun.  N3JLQ was automatic-GPS mobile and N2MSM was
manually entering his GPS position into his Porta-pkt TNC BText!  Both
stations hill-topped  around the area of the entourage so that they could be
used for digipeating to the big DIGI's...  We also saw our first Xcountry APRS
posit from WB6LPG in California!   A total of 55 APRS stations were observed
during the event and we all had fun!

------------------------------

Date: Fri, 3 Dec 1993 15:43:34 GMT
From: newsgate.watson.ibm.com!watnews.watson.ibm.com!sernews!news@uunet.uu.net
Subject: TEKK Radios
To: ham-digital@ucsd.edu

Can anyone tell me about the TEKK 440 based Radios?  I know they
are only 2watts, but are they good performers?  Any information
will be greatly appreciated.

73, Mike KB4LFH

====================================
KB4LFH @ VNET.IBM.COM
====================================

------------------------------

Date: Sat, 4 Dec 1993 13:40:38 GMT
From: butch!netcomsv!netcom.com!fmitch@uunet.uu.net
Subject: TEKK Radios
To: ham-digital@ucsd.edu

Felton Mitchell (fmitch@netcom.com) wrote:
: kb4lfh@vnet.ibm.com wrote:
: : Can anyone tell me about the TEKK 440 based Radios?  I know they
: : are only 2watts, but are they good performers?  Any information
: : will be greatly appreciated.

: : 73, Mike KB4LFH

: : ====================================
: : KB4LFH @ VNET.IBM.COM
: : ====================================

: hi mike... the tekk's work great! we are using one with a 20 watt brick
: for our main 9600 baud backbone node on 446.100... for the price,
: you can't go wrong... we have ordered 5 more to complete our
: backbone... we probably will use  tthe power amps out of some
: old commercial gear for a little higher power...

: the tekk expert is geoff, kd4goe, he is on the 'net and his
: 'net address is geoffp@netcom.com

: cul...
: mitch, wa4osr

oops... forgot to tell you one thing... the tekk's don't like
12 volts... you have to power them from 10-11 volts max, else
they aren't frequency stable... they pull such little current
this is not a problem, just a nusiance... 

mitch, wa4osr

-- 
-------------------------------------------------------------------------------
fmitch@netcom.com
Felton "Mitch" Mitchell, WA4OSR in Mobile, Alabama USA
205-342-7259 home, 205-476-4100 work, 205-476-0465 FAX
co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DXCluster in Mobile..
------------------------------------------------------------------------------

------------------------------

Date: 6 Dec 1993 02:46:29 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
Subject: TEKK Radios
To: ham-digital@ucsd.edu

The TEKK radio is ok for simple 9600 bps links.  The transmitter is
ok, and shows good modulation response when used with the typical 9600
bps modem - I've tried the TAPR and K9NG, and others report G3RUH modems
work ok.  The RF is more-or-less clean.  I'd recommend using a cavity
or other filter on it in most circumstances, and if it's going to be in
a place where there are other radios on nearby frequencies (such as at
a repeater site), a circulator or isolator wouldn't be a bad idea.

The receiver is only fair.  The front-end is easily smashed by strong
signals, so you need additional selectivity if your site has any other
transmitters nearby.  The IF bandpass filters are not ideal for 9600
bps, but if you have nice strong signals and reduce the transmitted
deviation, your digital signal will make it through ok.  Performance
is really poor at 9600 with weak signals, though.

I don't think I'm going to buy any more of them for our links.  Maxar
and Mitrek radios are available surplus for less and seem to be better.
 - Brian

------------------------------

Date: 5 Dec 93 18:01:05 GMT
From: news-mail-gateway@ucsd.edu
Subject: unsubscribe
To: ham-digital@ucsd.edu



------------------------------

Date: Thu, 02 Dec 93 21:45:13 ARG
From: ucsnews!sol.ctr.columbia.edu!math.ohio-state.edu!news.cyberstore.ca!nwnexus!a2i!satlink!burzaco!colla@network.ucsd.edu
Subject: Who should use gateways for what (was Re: wb7tpy gateway)
To: ham-digital@ucsd.edu

winter@apple.com (Patty Winter) writes:

>In article <1993Nov23.085806.17098@mnemosyne.cs.du.edu>,
>Jonathan Magee <jmagee@nyx10.cs.du.edu> wrote:
>>The only use of the internet in ham radio should be to connect ham
>>stations via worm holes ie only hams can use it.
>

Over long haul paths Internet could be considered one heck of a backbone
provided you can check both the origin and the destination are hams; some
countries might consider one side not being an amateur illegal, some others
not.

Beside that, as far as I know there is no regulations preventing amateurs
to send mail (unidirectionally) to the Internet world with a contents
within regulations.

I can also think in several things from the internet that could also be
carried legally over packet nets such as software, special bulletins,
emergency mail, etc; most of them usually served by automatic machines
and again with contents that could be considered otherwise legal if
exchanged between two licenced hams over the air.

To got an Internet hook, even an UUCP downstream feed not always is neither
cheap nor feasible.
------------------------------------------------------------------------------
Ing.Pedro E. Colla - Mail:colla@burzaco.satlink.net - Buenos Aires - Argentina

------------------------------

Date: Sat, 4 Dec 1993 19:40:53 +0000
From: news.sprintlink.net!demon!djwhome.demon.co.uk!david@uunet.uu.net
To: ham-digital@ucsd.edu

References <1993Nov23.163518.13551@hemlock.cray.com>, <2d08eo$mi4@wvhpadm1.mentorg.com>, <2d24se$dam@unicorn.ccc.nottingham.ac.uk>
Subject : Misroutes to Namibia usa.na domain (was: wb7tpy gateway) 

Well it looks from the DNS lookup that what is catching people out is a
very shallow domain name structure in Namibia.  My guess is that there is
little or no real Internet connectivity in Namibia so there is one mail
relay which forwards all mail by something like UUCP.  Thus a *.na MX
record is not unreasonable, as nearly all na mail needs to go to the
same relay and there is no point in recording individual sub-domains; a
lot of commercial domains do this.  I'm not sure about the na MX
records, but there is nothing technically wrong with them.

Although the mentorg.com example of dropping the domain name for local
traffic is largely true, it misses one significant point, which is
that you should not use top level domain names as subdomain names when
doing this.

Actually, in this particular case, there would seem to be a simple
solution within the domain name system which could avoid this problem.
All that needs to happen is for Namibia to add an MX record for
*.usa.na, pointing to a North American Internet to Packet gateway, or a
bit bucket (but the IP address must be good so that mailers don't try to
fall back to the *.na address).  With the former, as I understand it,
inbound mail needs human vetting, so a warning can be sent to the
originator and the mail optionally forwarded into the Packet network.
Alternatively, the gateway could just bounce it with an appropriate
message.

By doing this, at most, only a DNS query has to go to Namibia, and if
a long time to live is given for the entry any one source of such
misrouted mail should only rarely need to do this.

By the way, the logic behind the UK restriction on third party
traffic partly relates to the historic state monopoly on
telecommunications and partly to the idea that the radio spectrum is
commercially valuable, so amateurs, who get access well below the
market rate for the resource should not be able to compete with
commercial communication providers.  (I think that the US will only
allow third party traffic when both the countries involved allow it.)

I am copying this to the DNS administrator and postmaster for na, but to
fully implement it will need some cooperation from a US gateway.  So I
suggest that you agree as to which gateways should be targets of a
*.usa.na MX record and then the administrators of those gateways should
follow up to the na DNS administrator.  

-- 
David Woolley, London, England           david@djwhome.demon.co.uk

------------------------------

End of Ham-Digital Digest V93 #137
******************************
******************************
